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REMARKS/ARGUMENTS 

The Office Action of December 14, 2006, has been carefully reviewed and these remarks 
are responsive thereto. Independent claims 1, 8, 20, 28, 31, 32, and 39 have been amended. 
Claims 3-4, 15-16, 33-34 and 38 have been cancelled. Claims 1-2, 5-14, 17-22, 25-32, 35-37 and 
39 remain pending and allowance of the instant application are respectfully requested. 

Claim Rejections Under 35 U.S.C. §1 03(a) 

Claims 1-6, 8-18, 20-26, 28-29, 31-36, and 39 were rejected under 35 U.S.C. §103(a) as 
being unpatentable over Bertrand ei al. (U.S. patent No. 6,687,252, hereinafter "Bertrand") in 
view of Takeda et al. (U.S. Publication No. US 2001/0048686 Al) and further in view of 
Applicant's alleged admitted prior art (as found in Applicant's specification at paragraph 8). This 
rejection is respectfully traversed for the following reasons. 

Applicant respectfully incorporates by reference in its entirety the Response filed October 
4, 2006 to the non-final Office Action mailed July 25, 2006. 

Independent claims 1, 8, 20, 28, 31, 32, and 39 all relate to, inter alia, a GGSN assigning 
one of a private network address and a public network address to a mobile station based on 
information contained in an APN field of an Activate PDP context request or a Create PDP 
Context Request message. The information contained in the APN field is transmitted by the 
requesting mobile terminal and explicitly indicates requesting one of a private network address 
and a public network address. As recognized in the Office Action, neither Bertrand nor Takeda, 
either separately or in combination, teaches or suggests such a feature. Neither Bertrand and 
Takeda teaches or suggests assignment of a private or a public network address be based on 
information in the APN field that explicitly indicates requesting one of a private network address 
and a public network address as requested by the mobile station. Neither Bertrand nor Takeda 
provides any independent motivation or suggestion to combine the use of APNs with the 
assignment of network addresses in the manner suggested by the Applicant. 

By way of example, claim 1 of the present application, as amended claims in part: "a 
Serving GPRS Support Node (SGSN) receiving an Activate Packet Data Protocol (PDP) Context 
Request message from a mobile station of the GPRS-based communications network, the Activate 
PDP Context Request message having an APN field containing information that explicitly 
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indicates requesting one of a private network address and a public network address." Support for 
this amendment can be found in at least pages 13-14 of the present application (see also 
paragraph 40 of the present application, as published, U.S. Patent Application Publication No. US 
2003 as 2003/01 12793). 

Claim 1 also claims "the SGSN sending a Create PDP Context Request message from the 
SGSN to the GGSN in response to the Activate PDP Protocol Context Request, the Create PDP 
Context Request message having an APN field containing information relating to a request for 
one of a private network address and a public network address." 

As recognized in the final Office Action (at pp. 3-4), Bertrand does not disclose that an 
Activate PDP Context Request message and a Create PDP Context Request have an APN field 
containing information relating to a request for one of a private network and a public network 
address. 

As recognized in the final Office Action (at p. 4), Bertrand also does not disclose that the 
public network address or private network address is assigned based on information contained in 
the APN field of the Create PDP Context Request message. 

The Office Action states that Takeda discloses an Activate PDP Context Request message 
and a Create PDP Context Request message that have an APN field containing information 
relating to a request for an address - specifically an APN field containing information identifying 
a destination network gateway node. There is, however, no teaching Takeda that the 
identification of this destination network gateway node includes an identification of whether the 
node is one of a private network address and a public network address. 

Additionally in Takeda, it is the DHCP server that assigns the IP address to the mobile 
terminal, not the gateway node. P. 6, f 95. Even so, Takeda does not teach or suggest that the 
DHCP, in allocating BP addresses, evaluates or receives any information contained in the APN 
relating to the mobile terminal's request for one of a public network address or a private network 
address. Neither Bertrand nor Takeda provides any independent motivation or suggestion to 
combine the use of APNs with the assignment of network addresses in the manner suggested by 
the Applicant. There is certainly no suggestion in either Bertrand or Takeda for an "Activate PDP 
Context Request message having an APN field containing information that explicitly indicates 
requesting one of a private network address and a public network address." 
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The Office Action states that it would have been obvious for one of ordinary skill in the 
art at the time of the invention, when presented with the work of Takeda et al., to combine using 
an Activate PDP Context Request message and a Create PDP Context Request message that have 
an APN field containing information relating to a request for an address, as suggested by Takeda 
et al, with the system and method of Bertrand et al., with the motivation being to allow address 
assignment to be based on the destination network that a mobile station is requesting to 
communicate with. It is not seen, however, where Bertrand or Takeda teaches any benefit in 
having an address assignment be based on a particular type of destination network address. 
Neither Bertrand nor Takeda teach any benefit in having an address assignment be one of a 
private network address and a public network address. 

In short, Takeda does not provide a motivation to modify Bertrand to allow address 
assignment to be based on the type of destination network address. Takeda does not provide a 
motivation in having an address assignment be one of a private network address and a public 
network address. Bertrand or Takeda do not alone or in combination teach an "Activate PDP 
Context Request message having an APN field containing information that explicitly indicates 
requesting one of a private network address and a public network address" as claimed in 
independent claims 1, 8, 20, 32 and 39, as amended. Similarly, Bertrand or Takeda do not alone 
or in combination teach a "Create PDP Context Request message having an APN field containing 
information that explicitly indicates requesting one of a private network address and a public 
network address" as claimed in independent claims 28 and 31, as amended (see paragraphs 40-41 
of the present application, as published, U.S. Patent Application Publication No. US 2003. as 
2003/0112793). 

Absent motivation to modify Bertrand to allow address assignment to be based on the type 
of destination network address, there is certainly no motivation to further modify Bertrand to 
provide for an Activate or a Create PDP Context Request message having an APN field 
containing information that explicitly indicates requesting one of a private network address and a 
public network address as claimed in independent claims 1, 8, 20, 28, 31, 32 and 39, as amended. 

As recognized in the final Office Action, the teachings of Bertrand et al. and Takeda et al. 
do not disclose explicitly indicating one of a request for a private network address and a public 
network address (see page 18 of the final Office Action). The Office Action states that in the 
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rejections Official Notice has been taken that explicitly indicating that one of a private network 
address and a public network address in a request is old and well known in the field of 
communications. The Office Action cites Applicant's alleged admitted prior art (paragraph 8), 
and "[n]ewly cited Publication Iyer (U.S. Publication US 2002/01 16502)" as "proof that explicitly 
indicating one of a private network address and a public network address in a request is old and 
well known in the field of communications." 

Paragraph 8 of applicant's application as published, as well as newly cited Iyer, describes 
the use of a Network Address Translator (NAT). As noted in the Response filed October 4, 2006, 
Applicant's Background of the Invention does not remedy the deficiencies in Bertrand and 
Takeda. Paragraph 8 (of the present application, published as U.S. Patent Application Publication 
203/01 12793) describes the use of a Network Address Translator (NAT). A NAT is used when a 
host that is assigned to a private address within an administrative domain intends to send an IP 
address (and possibly other selected fields within the datagram) into a public EP address prior to 
the IP datagram being sent outside the administrative domain associated with the NAT. A NAT 
transforms a private IP address (and possibly other selected fields within the datagram) into a 
public IP address prior to the DP datagram being sent outside the administrative domain associated 
with the NAT. Similarly, when an IP datagram is sent from a host that is outside the 
administrative domain associated with the NAT to a host with a private address, then the NAT 
transforms a public IP address to a private address. 

A NAT does not conserve public IP addresses and simultaneously maintain end-to-end 
security and application friendliness. Indeed, as explained in paragraph 11 of the present 
application as published, there are two major drawbacks associated with the use of a NAT. The 
first major drawback is that the NAT-based approach breaks the end-to-end security model by 
changing the destination address of a datagram and thereby invalidating the authentication header 
of the datagram. The second major drawback is that certain types of applications cannot work in 
the presence of a NAT, unless remedial measures are taken, such as the inclusion of an 
application gateway (proxy). For example when an IP address is embedded into an application 
protocol unit (PDU), an ALG (Application Level Gateway) is required so that the embedded IP 
address is changed because a conventional NAT-based address assignment operation will not 
change the embedded IP address. 
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As explained in paragraph 12 of the present application as published, in order to overcome 
the disadvantages associated with NATs, i.e., the security break and the "unfriendliness" toward 
some applications, a mechanism commonly referred to as Realm Specific IP (RSIP) has gained 
significant support within the Internet Engineering Task Force (IETF). As noted in paragraphs 
13-17 of the present application, RSIP protocol makes use of a NAT unnecessary, and thereby 
avoids the drawbacks involving NATs. 

As explained in paragraph 18 of the present application as published, in the case of a 
General Packet Radio System (GPRS) network or a GPRS-based network (such as a Universal 
Mobile Telecommunications System (UMTS)), a Mobile Station (MS) is assigned an IP address 
by a Gateway GPRS Support Node (GGSN). Currently, such an IP address is an IPv4 address. 
The protocol that is used for address assignment is specific to GPRS networks and is referred to 
as PDP Context Activation. PDP (Packet Data Protocol) is an acronym that is used within GPRS 
networks to refer to IP addresses, X.25 addresses, etc. An administrative domain within GPRS 
networks (and within cellular networks, in general) is referred to as a PLMN (Public Land Mobile 
Network). 

As explained in paragraph 19 of the present application as published, FIG. 3 shows 
generic GPRS protocol stacks for a mobile station (MS), base station subsystem (BSS), Serving 
GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). The IP address for 
the MS may be seen on the protocol stack for the MS. 

As explained in paragraph 20 of the present application as published, FIGS. 4a-4d 
illustrate a conventional PDP (Packet Data Protocol) context activation sequence within a GPRS 
network. During the first step of a conventional PDP context activation shown in FIG. 4a, an MS 
sends an Activate PDP Context Request message to an SGSN through a BSS. The Activate PDP 
Context Request message contains appropriate information in the NSAPI, PDP type, PDP Addr, 
APN, QoS Req, and PDP Config Options in a well-known manner. In FIG. 4b, the SGSN sends a 
Create PDP Context Request message to a GGSN containing appropriate information in the PDP 
Type, PDP Addr, APN, QoS Negotiated, TID, Selection Mode, PDP Config Options fields. In 
FIG. 4c, the GGSN sends a Create PDP Context Response message to the SGSN containing 
appropriate information in the TID, PDP Addr, BB Protocol, Reordering Reqd, QoS Negot., PDP 
Config Options and Cause fields. In FIG 4d, the SGSN then sends an Activate PDP Context 
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Accept message to the MS containing appropriate information in the NSAPI, PDP Type, PDP 
Addr, QoS Req, Radio Priority Level and PDP Config Options field. 

As explained in paragraph 21 of the present application as published, nevertheless, the 
GPRS standard does not specify whether private or public IP addresses are assigned to a 
requesting MS. Address assignment is not a standardization issue because a NAT is currently 
used at a PLMN boundary when private IP addresses are used. That is, current GPRS 
deployments rely on NATs at the GGSN when private addresses are assigned to a requesting MS. 
While this handles the problem of conserving IPv4 addresses, end-to-end security or application 
friendliness is not provided. 

As noted in paragraph 22 of the present application as published, even though a 
conventional PDP context activation procedure within a GPRS network assigns an IPv4 address 
to a mobile station, what is needed is a technique for assigning an IPv4 address to a mobile station 
in a GPRS network or a GPRS-based network that conserves IPv4 addresses and simultaneously 
maintains end-to-end security and application friendliness. 

The present application provides just such a technique, not heretofore available or 
provided or suggested by the prior art. 

In view of the drawbacks involving NATs, and the teaching away of using NATs by using 
RSIP protocol, one of ordinary skill in the art would not be motivated to incorporate a NAT into a 
combination of Bertrand and Takeda to provide the present invention. Even if a NAT is 
incorporated into a combination of Bertrand and Takeda, the combination of the three references 
would not result in the present invention. A NAT does not involve an Activate or a Create PDP 
Context message having an APN field containing information that explicitly indicates requesting 
one of a private network address and a public network address. Rather, a NAT simply transforms 
a private IP address into a public IP address when a host intends to send an IP datagram to a host 
that is outside the administrative domain of the sending host. 

Independent claims 1, 8, 20, 32, and 39 relate to, inter alia, information contained in the 
APN field of the Activate PDP Context Request message explicitly indicating one of a private 
network address and a public network address. Independent claims 28 and 31 relate to, inter alia, 
information contained in the APN field of the Create PDP Context Request message explicitly 
indicating one of a private network address and a public network address. 
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As discussed on pages 13-14 of Applicant's specification (paragraph [40] as published), 
the inserted information (in the APN field) relating to whether a public or a private address 
assignment is desired can be an explicit indication, such as a particular bit (or bits) of the APN 
field being set. Neither Bertrand nor Takeda nor a NAT, separately or in combination, teaches or 
suggests such a feature. The Office Action even admits this deficiency of Bertrand and Takeda. 
Instead, the Office Action alleges that 26-27, 71-72, and 89-90 of Takeda disclose an "an 
Activate PDP Context Request message and a Create PDP Context Request message that have an 
APN field containing information relating to a request for an address." Even assuming the 
validity of such an allegation, merely containing information relating to a request is 
distinguishable from containing information in the APN field explicitly indicating one of a private 
network address and a public network address. Significantly, the cited passages only disclose an 
APN for identifying a gateway node. There is no teaching or suggestion that the APN field 
includes any explicit indicators of whether a private network address or a public network address 
is being requested. 

The Office may not use Applicant's invention as a blueprint for combining distinct 
components/features found in Bertrand, Takeda, and a NAT as described in paragraph 8 of the 
present application (or newly cited Iyer). As such, claims 1, 8, 20, 28, 31, 32 and 39 are 
allowable for at least this reason. 

Claims 2, 5-7, 9-14, 17-19, 21-27, 29, 30 and 35-37 are allowable for at least the same 
reasons as their respective base claims and further in view of the novel and non-obvious features 
recited therein. 

Additional Claim Rejections in view of fourth cited reference, Boudreaux 

Claims 7, 19, 27, 30 and 37 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Bertrand in view of Takeda and Applicant's alleged admitted prior art on NAT as applied to 
claims 1-6, 8-18, 20-26, 28-29, 31-36 and 39 above, and further in view of Boudreaux (U.S. 
Patent No. 6,466,556). This rejection is respectfully traversed for the following reasons. 

Claims 7, 19, 27, 30 and 37 all relate to a GPRS-based communications network that is a 
Universal Mobile Telecommunications System. The Office Action concedes that Bertrand and 
Takeda and Applicant's alleged admitted prior art does not disclose such a feature. While 
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Boudreaux may teach a Universal Mobile Telecommunications System, it does not remedy the 
failure of Bertrand, Takeda, and paragraph 8 of Applicant's specification regarding alleged prior 
art (or newly cited Iyer) to teach the claimed invention of the independent claims upon which 7, 
19, 27, 30 and 37 depend from. As such, claims 7, 19, 27, 30 and 37 are allowable for over the 
proposed combination of Bertrand, Takeda, Applicant's alleged admitted prior art regarding NAP 
(or newly cited Iyer), and Boudreaux. 



All rejections having been addressed, Applicants respectfully submit that the instant 
application is in condition for allowance, and respectfully solicits prompt notification of the same. 
However, if for any reason the Examiner believes the application is not in condition for allowance 
or there are any questions, the Examiner is requested to contact the undersigned at (312) 463- 
5405. 



CONCLUSION 



Respectfully submitted, 



Dated: January 23, 2007 



By: /Robert H. Resis/ 

Robert H. Resis 
Registration No. 32,168 
BANNER & WITCOFF, LTD. 
10 South Wacker Drive, Suite 3000 
Chicago, IL 60606 
Direct Dial: 312-463-5405 
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